home *** CD-ROM | disk | FTP | other *** search
/ MacWorld 2000 February / Macworld (2000-02).dmg / Mac ISPs / AppleOnline Installer.sea / AppleOnline Installer / Software Installers / MacOS Networking Software / Open Transport 1.3.1 / OT 1.3 Technical Info < prev    next >
Text File  |  1998-01-01  |  25KB  |  267 lines
  2. Open Transport 1.3 Technical Information
  3.  
  4.  
  5. This document contains technical information about Open Transport that may be useful to network managers and administrators. You do not need to read this document in order to use Open Transport. 
  6.  
  7.  
  8. Contents
  9.  
  10. Introduction
  11. Files added by the Open Transport installer
  12. Open Transport AppleTalk features
  13.             - Static and dynamic AppleTalk address allocation
  14.             - Use of parameter RAM
  15. Open Transport TCP/IP features
  16.             - DHCP server support
  17.             - DHCP address lease support
  18.             - Windows NT advanced server support
  19.    - BootP support
  20.             - Local Hosts file support
  21.    - Single Link Multi-homing System Setup
  22.             - MacTCP “server” addressing support
  23.             - MacTCP “dynamic” addressing support
  24.             - MacIP support
  25.             - PPP connectivity
  26. Memory requirements
  27. Application compatibility guidelines
  28. Performance
  29.  
  30.  
  31. Introduction
  32.  
  33. Open Transport is modern networking and communications system software for the Mac OS. It is based on industry standards and brings a new level of networking connectivity, control, and compatibility to Mac OS computers, while preserving built-in support for easy-to-use networking. Open Transport is supported on system software versions 7.1, 7.1.1, 7.1.2, 7.5.3, 7.5.5 or later. System software version 7.5.3 or later is recommended. No other system software versions are supported.
  34.  
  35. For more important information about system requirements, compatibility, and known incompatibilities and limitations, read the "About Open Transport 1.2" document.
  36.  
  37.  
  38. Files added by the Open Transport installer
  39.  
  40. Open Transport installs the AppleTalk and TCP/IP control panels into the Control Panels folder inside the System Folder of your startup disk. The Open Transport Installer also adds the following files to the Extensions folder inside the System Folder:
  41.  
  42. Shared Library Manager
  43. Shared Library Manager PPC
  44. These extensions implement a shared library mechanism on 68K and PowerPC Mac OS computers, respectively. Both extensions are required on PowerPC-based computers in order to support both emulated and native shared libraries.
  45.  
  46. OpenTransportLib
  47. Open Transport Library
  48. These shared libraries implement core Open Transport services on both 68K and PowerPC-based computers. The first library contains the PowerPC implementation and an interface for native PPC applications. The second library contains the built-in Open Transport modules and an interface for emulated 68K applications.
  49.  
  50. OpenTptAppleTalkLib
  51. Open Tpt AppleTalk Library
  52. These shared libraries implement Open Transport AppleTalk services on both 68K and PowerPC-based computers. The first library contains the PowerPC implementation and an interface for native PPC applications. The second library contains the built-in Open Transport modules and an interface for emulated 68K applications.
  53.  
  54. OpenTptInternetLib
  55. Open Tpt Internet Library
  56. These shared libraries implement Open Transport TCP/IP services on both 68K and  PowerPC-based computers. The first library contains the PowerPC implementation and an interface for native PPC applications. The second library contains the built-in Open Transport modules and an interface for emulated 68K applications.
  57.  
  58. Open Transport 68K Library
  59. This shared library implements core Open Transport services on 68030- and 68040-based computers.  It is installed instead of Open Transport Library if "Open Transport for 68k Macintoshes" is selected in a Custom Install.
  60.  
  61. Open Tpt ATalk 68K Library
  62. This shared library implements Open Transport AppleTalk services on 68030- and 68040-based computers.  It is installed instead of Open Tpt AppleTalk Library if "Open Transport for 68k Macintoshes" is selected in a Custom Install.
  63.  
  64. Open Tpt Inet 68K Library
  65. This shared library implements Open Transport TCP/IP services on 68030- and 68040-based computers.  It is installed instead of Open Tpt Internet Library if "Open Transport for 68k Macintoshes" is selected in a Custom Install.
  66.  
  67. OpenTransportLib.68K
  68. This shared library implements CFM 68k API for Open Transport.  Used by Apple and 3rd party network applications on  68030- and 68040-based computers that use the Code Fragment  Manager.  It is installed instead of OpenTptInternetLib if "Open Transport for 68k Macintoshes" is selected in a Custom Install.
  69.  
  70.  
  71. Open Transport AppleTalk Features
  72.  
  73. Static and dynamic AppleTalk address allocation
  74.  
  75. Open Transport AppleTalk supports static assigned (manually administered) protocol addresses as well as the dynamic addressing provided by AppleTalk Address Resolution Protocol (AARP). Static addressing allows AppleTalk nodes to be managed using the protocol address as a unique and stable identifier. 
  76.  
  77. It is important that all nodes on each individual AppleTalk subnet (a given cable segment assigned a unique network number or network number range) be administered consistently—either all with dynamic addressing or all with pre-assigned static addresses. This avoids a potential conflict when a new dynamic node acquires an address assigned to manually-addressed node that is not connected or is off line. Administrators can enforce the addressing policy for a subnet by locking the addressing mode. As a precaution, Open Transport AppleTalk checks for duplicate protocol addresses on the LAN even when static addressing is configured.
  78.  
  79. Use of parameter RAM
  80.  
  81. Under classic AppleTalk, AppleTalk’s on/off state, the selected network interface, the previous network (protocol) address, and the previous AppleTalk zone name are saved in persistent memory (parameter RAM) for reuse at startup. To ensure backward compatibility, this information is still stored and retrieved on systems using Open Transport AppleTalk. However, the following differences are found with Open Transport:
  82.  
  83. •  At startup, Open Transport reads the current AppleTalk configuration file to determine if AppleTalk should be turned on or off. This value overrides the value saved in parameter RAM. The user is not explicitly notified when this occurs.
  84.  
  85. •  If the network interface specified in the current AppleTalk configuration file is locked and the specified port is not available or cannot be initialized, Open Transport will not automatically switch the port back to LocalTalk. Instead, AppleTalk will remain off. The user sees a dialog box with this information.
  86.  
  87. Open Transport TCP/IP features
  88.  
  89. Open Transport brings a workstation-class implementation of TCP/IP protocols to Mac OS. As with MacTCP, Open Transport TCP/IP is a full 32-bit stack. Open Transport TCP/IP adds support for:
  90.  
  91. •    dynamic path MTU discovery, for more efficient network use in heterogeneous network topologies.
  92.  
  93. •    Dynamic Host Configuration Protocol (DHCP), for centralized IP address configuration management.
  94.  DHCP is an Internet Engineering Task Force (IETF) standards-track protocol.
  95.  
  96. •    IP multicast, for participation as an MBone client for applications written to the native Open Transport API.
  97.  
  98. •    simultaneous TCP connections for applications written to the native Open Transport API are limited only by installed memory and processor power, for increased functionality as an Internet or other TCP/IP network server.
  99.  
  100. •    a new, more robust and standards-compliant domain name resolver (a caching stub DNR).
  101.  
  102. •    support for developer access to raw IP services, as well as TCP and UDP.
  103.  
  104. •    Ethernet Version 2.0 and IEEE 802.3 framing, for better interoperability with a wider range of TCP/IP hosts.
  105.  
  106. •    implicit and explicit domain name search paths, for increased control of domain name resolution.
  107.  
  108. •    use of multiple IP routers with fail-over, for increased robustness in mission-critical applications. 
  109.  
  110. • TCP wildcard source port assignments start at 2048, increasing from that point.
  111.  
  112. DHCP server support
  113.  
  114. Apple’s implementation conforms to the current versions of the applicable specification documents (RFCs). To date, Open Transport TCP/IP has been tested with the following DHCP server implementations:
  115.  
  116. •    Competitive Automation  (URL: http://www.join.com)
  117. •    FTP Software  (URL: http://www.ftp.com)
  118. •    Hewlett Packard HP-UX (URL: http://www.hp.com)
  119. •    Microsoft Windows NT Advanced Server (URL: http://www.microsoft.com)
  120. •    Silicon Graphics  (URL: http://www.sgi.com)
  121. •    Sun Solaris and SunOS (URL: http://www.sun.com)
  122. •    TGV (URL: http://www.tgv.com)
  123.  
  124. DHCP address lease support
  125.  
  126. Open Transport TCP/IP supports DHCP address leases. Open Transport TCP/IP automatically attempts to renew any address lease that reaches its renewal interval (by default, the renewal interval is reached when the lease is halfway completed). The renewal interval may be configured to a different value by making changes to the configuring DHCP server. Renewal is attempted regardless of how many times the lease has already been renewed. Lease rebinding is also supported. Should an interface's IP address lease expire, the interface is closed down. Open Transport TCP/IP does not currently support the DHCP Client ID option or the DHCPINFORM message, nor will it currently try to use the remainder of a previous but unexpired lease upon rebooting.
  127.  
  128. Windows NT advanced server support
  129.  
  130. With Open Transport 1.1 and later, Mac OS clients are interoperable with the Windows NTAS DHCP server on LAN links. However, Mac OS clients cannot acquire configuration information from an NT DHCP server across a dialup (PPP) link because there is not yet an accepted industry standard for DHCP over dialup. The NT implementation is based on proprietary Microsoft extensions. Mac OS clients cannot acquire configuration information nor register with a Microsoft WINS server. WINS is also dependent on Microsoft extensions to TCP/IP (requiring NetBIOS support). 
  131.  
  132. The Internet Engineering Task Force (IETF) is developing a cross-platform industry standard technology for dynamic registration and look-up of IP names through the Dynamic Service Location working group. Apple has no current plans to implement the WINS extensions. Instead, we are fully committed to implementation of the applicable IETF standards as they emerge.
  133.  
  134. Macintosh clients running versions of Open Transport prior to 1.1 could experience some interoperability problems due to other significant differences between the Microsoft implementation and that of a typical UNIX-based server.
  135.  
  136. BootP support
  137.  
  138. Open Transport 1.1 and later fully supports Bootstrap Protocol (BootP). Versions of Open Transport prior to 1.1 failed to accept a BootP Reply sent to the unicast (subnet broadcast) address, (for example, xxx.xxx.xxx.255. Replies sent to the all-nets broadcast address (for example, 255.255.255.255) were handled properly. Also, earlier versions of Open Transport required that the BootP gateway be zero hops away.
  139.  
  140. Local Hosts file support
  141.  
  142. Open Transport TCP/IP supports a Hosts file that may be used to supplement and/or customize the Domain Name Resolver’s initial cache of information. The Hosts file is normally stored in the Preferences folder in the active System Folder. When Open Transport TCP/IP is initialized, it reads the Hosts file (if any). As in MacTCP, the supported Hosts file features follow a subset of the Domain Name System Master File Format (RFC 1035).
  143.  
  144. Open Transport TCP/IP is more stringent regarding the content and format of the Hosts file than was MacTCP, which permitted violation of the FQDN requirement for <domain-name>. For instance, the format:
  145.  
  146. charlie              A      128.1.1.1
  147.  
  148. which was acceptable to the MacTCP DNR, is no longer permitted because of the use of domain search lists in Open Transport/TCP (“charlie” could potentially exist in any or all of the configured domains). To accomplish the same effect, use this format instead:
  149.  
  150. charlie              CNAME  myhost.mydomain.edu
  151. myhost.mydomain.edu  A      128.1.1.1
  152.  
  153. This associates the local alias charlie with the fully qualified domain name myhost.mydomain.edu, and resolves it to the address 128.1.1.1. Use of local aliases is limited to CNAME entries; NS and A entries must use fully qualified domain names.
  154.  
  155. You can create a Hosts file with any text editor or word processor (the Hosts file must be stored in text format).  If you use a Hosts file, keep it as short as possible, and include only entries that will be accessed frequently. This reduces the memory required to cache the DNS information and minimizes the need to maintain and update Hosts files as system information changes.
  156.  
  157. Open Transport TCP/IP automatically uses a Hosts file stored the Preferences folder of the active System Folder. If no Hosts file is found in the Preferences folder, Open Transport TCP/IP searches the active System Folder for a Hosts file. You can specify a particular Hosts file to use with a specific configuration. For example, one Hosts file might be set up for a user connecting via Ethernet, and another set up for when that user connects via modem.
  158.  
  159. For additional information about the Hosts file design of the Open Transport Domain Name Resolver, see the document “Apple Open Transport Reference Q&A.” The latest version of the Q&A is in the Open Transport Extras Folder and is available on the Internet at ftp://seeding.apple.com/ess/public/opentransport/.
  160.  
  161. Single Link Multi-homing System Setup
  162.  
  163. Open Transport 1.3 introduces Single Link Multi-homing, a mechanism by which Open Transport can support multiple IP addresses on the same hardware interface.  Synonyms for this feature include IP Aliasing, Secondary IP address Support, IP Masquerading, "Multihoming", IP Multinode support.  This is useful for sites like Internet Service Providers (ISPs), that want to give each of their clients a distinct IP address, without requiring separate computers for each address.  Web server software packages, or server plug-ins that utilize this feature can offer virtual domain support that supports all web browsers.  You will need to contact your application developer to see if they are supporting this new feature of Open Transport.  This feature is only available with Open Transport 1.3 and later. 
  164.  
  165. You configure a system to use multiple IP addresses as follows:
  166.  
  167. 1.  The TCP/IP Control Panel must be set for manual addressing. 
  168.  
  169. 2.  You create a text file with the required name "IP Secondary Addresses" and put it into the Preferences folder in the System Folder.
  170.  
  171. Each line of the IP Secondary Addresses file contains a secondary IP address to be used by the system, and an optional subnet mask and router address for the secondary IP address.  If there is no subnet mask entry, then a default subnet mask for the IP address class will be used.  If there is no router address entry, then the default router associated with the primary address will be used.
  172.  
  173. Each secondary address entry must be prefixed by "ip=".  Each subnet mask entry must be prefixed by "sm=".  Each router address entry must be prefixed by "rt=". Lines proceeded by a ; are ignored.  An example of the contents of the IP Secondary Addresses file follows.
  174.  
  175. ; 'ip=' for ip address, 'sm=' subnet mask, 'rt=' router address
  176. ;  Note: no space in 'ip=192.168.22.200'
  177. ;
  178. ; IP address                   Subnet Mask              router addresses
  179. ;-----------             -----------              ----------------
  180. ip=192.168.22.200              sm=255.255.255.0         rt=192.168.20.1
  181. ip=192.168.22.201                                 rt=192.168.20.1
  182. ip=192.168.22.202
  183.  
  184. The order of the entries is important.  The "rt=" entry  must follow the "sm=" entry if used.
  185.  
  186. When Open Transport activates TCP/IP, the primary address will be obtained from the TCP/IP Control Panel setting.  Open Transport then looks for the IP Secondary Addresses file in the Preferences folder to determine if additional addresses should also be configured.  If there are duplicate IP address entries in the IP Secondary Addresses file, the duplicate addresses will be ignored.  When Open Transport binds a TCP/IP connection, if there is an address conflict with either the primary or any secondary addresses with another host, Open Transport will present an error message using a dialog box and unload Open Transport/TCP from memory. The error dialog will display the conflicting IP address, the hardware address of the conflicting machine and note that your TCP/IP network interface has been shut down.
  187.  
  188. To resolve the conflict, quit all of the TCP/IP applications on both conflicting machines, reconfigure TCP/IP on one of the machines so there is no longer an address conflict, then relaunch your TCP/IP applications.
  189.  
  190. MacTCP “server” addressing support
  191.  
  192. Open Transport TCP/IP supports both Bootstrap Protocol (BootP) and Reverse Address Resolution Protocol (RARP) configuration methods. MacTCP Server mode addressing was a combination of BootP and RARP. When Server mode was selected, MacTCP used BootP to attempt to acquire an IP address. If that failed, MacTCP tried RARP. Whichever protocol was successful was stored as a preference, and was used first the next time the computer started up. In Open Transport, you must choose BootP or RARP explicitly.
  193.  
  194. MacTCP “dynamic” addressing
  195.  
  196. Open Transport does not support MacTCP “dynamic” addressing. MacTCP dynamic mode addressing was based on an Apple-proprietary extension to TCP/IP protocols. It applied the address negotiation and assignment rules used by the AppleTalk protocols to TCP/IP networks, making it very easy to set up a Macintosh-only standalone TCP/IP network. Use of this dynamic addressing method in other scenarios, however, could create additional work for a network administrator. 
  197.  
  198. The Internet community (IETF) has since developed a multivendor standard for the dynamic assignment of IP addresses, known as Dynamic Host Configuration Protocol (DHCP). Open Transport TCP/IP supports the industry standard DHCP.
  199.  
  200. MacIP support
  201.  
  202. MacIP is a protocol specification developed for carrying TCP/IP traffic on AppleTalk-only networks, originally LocalTalk networks. MacIP is today frequently used with AppleTalk Remote Access Protocol (ARAP) to provide mobile users access to TCP/IP network services.
  203.  
  204. Use of MacIP typically requires a gateway, which strips off the AppleTalk encapsulation and places the IP packet on the TCP/IP LAN. When packets are sent back to the MacIP end-node, the gateway replaces the AppleTalk encapsulation. MacIP gateway support is most frequently offered as an integrated service within a multiprotocol router. The gateway (router) attaches to both an AppleTalk and a TCP/IP network. 
  205.  
  206. Open Transport supports MacIP in the TCP/IP control panel. Once selected, TCP/IP data is encapsulated in AppleTalk packets, and is sent through the selected network interface.
  207.  
  208. PPP connectivity
  209.  
  210. PPP (Point to Point Protocol) connectivity for Open Transport is currently based STREAMs modules or on the use of third-party software extensions known as “MDEVs.” Early versions of some MDEVs may not be compatible with Open Transport. For information about MDEV compatibility, see both parts of the "Open Transport 1.3 ReadMe" document.
  211.  
  212. STREAMs based PPP solutions are available from Apple and selected 3rd parties. Open Transport/PPP and Apple Remote Access 3.0 both use STREAMs.  For more information about PPP see both parts of the "Open Transport 1.3 ReadMe" document.
  213.  
  214. Memory requirements
  215.  
  216. Open Transport provides many new features and capabilities to Mac OS customers and, in general, will require more system memory (RAM) than does classic networking. However, the actual memory requirements of Open Transport vary depending upon the networking services in use at a given time. This is different from classic networking, which allocates memory to networking services and keeps it allocated even after networking services are no longer in use.
  217.  
  218. Factors contributing to differences in memory requirements include:
  219.  
  220. •    Open Transport provides implementations of networking as both 680x0 and native PowerPC code. PowerPC code is typically larger (but also faster).
  221.  
  222. •    Open Transport provides “mixed-mode” applications support, making it possible for both PowerPC native and 680x0 applications to use native networking on PowerPC-based computers.
  223.  
  224. •    Open Transport includes both the new implementations of networking and the libraries required to provide backward compatibility support for the older AppleTalk and MacTCP programming interfaces.
  225.  
  226. •    Open Transport requires less memory on systems with virtual memory enabled. Classic networking has about the same memory requirements regardless of the VM setting.
  227.  
  228. •    Open Transport is based on the cross-platform standard STREAMs environment, which requires more memory than classic networking.
  229.  
  230. The difference in memory requirements depends upon the configuration of your computer. Some examples of base memory requirements include:
  231.  
  232.                   Virtual             Classic                  Open
  233. Computer System    Memory       AppleTalk & MacTCP          Transport
  234. ------------------------------------------------------------------------
  235. PowerPC-based        On            350K to 450KB               200KB
  236. PowerPC-based        Off           350K to 450KB           up to 1.2MB
  237. 608x0-based          Off           350K to 450KB          700KB to 800KB
  238.  
  239.  
  240. Application compatibility guidelines
  241.  
  242. Apple has defined three levels of interoperability with Open Transport. The first, “Open Transport Compatible,” is used to describe network applications originally developed for “classic” AppleTalk or MacTCP programming interfaces that now take advantage of Open Transport Compatibility Services. These applications automatically gain the benefits associated with the Open Transport control panels. However, they will not realize a significant performance increase on Power Macintosh systems, nor can they take advantage of Open Transport’s transport-independence capabilities.
  243.  
  244. “Open Transport Ready” applications have adopted the new Open Transport APIs. They are PowerPC native, in addition to running on 680x0-based Macintosh systems. Open Transport-ready applications benefit from the new control panels and may also realize a significant performance boost when running on PowerPC-based computers.
  245.  
  246. The highest category of interoperability is “Open Transport Enhanced.” In addition to adopting the new Open Transport APIs and being Power PC native, these applications can be dynamically configured to support AppleTalk, TCP/IP, or serial communication.
  247.  
  248. Applications that rely on undocumented APIs or examine private data structures in AppleTalk or MacTCP may not be fully compatible with Open Transport. Updated versions of these software products will be required for full compatibility.
  249.  
  250.  
  251. Performance
  252.  
  253. Open Transport is designed to take advantage of the PowerPC processor. For maximum performance, however, networking applications must also take advantage of the PowerPC processor, and should adopt the new Open Transport programming interfaces.
  254.  
  255. In general, current Mac OS networking applications are written for the 680x0 processor and use the “classic” (680x0-based) networking programming interfaces. These applications can still be used with Open Transport, and may perform somewhat better. Networking applications that are PowerPC-native but not Open Transport-ready may yield better performance, but still fall short of the maximum potential performance because they make use of Open Transport backward compatibility rather than its full capabilities. 
  256.  
  257. Performance improvements will be greater with protocols that use larger datagram sizes. For example, TCP/IP users will see greater improvements than AppleTalk users, because AppleTalk has a fixed and limited datagram size. On high-speed datalinks such as fast Ethernet, FDDI, and ATM, the performance of the network interface card (NIC) driver code is also a significant factor.
  258.  
  259. Overall performance also depends on the amount of RAM available. Larger packet sizes and higher throughput place increased demand on the buffering system of Open Transport. If Open Transport becomes low on memory, throughput decreases to accommodate the limitation.
  260.  
  261.  
  262. ©1997 Apple Computer. Inc.
  263. Apple, the Apple logo, AppleShare, AppleTalk, LaserWriter, LocalTalk, MacTCP, Performa, Power Macintosh, PowerBook, and PowerBook Duo are trademarks of Apple Computer, Inc., registered in the U.S. and other countries. NuBus is a trademark of Texas Instruments. PowerPC is a trademark of International Business Machines Corporation, used under license therefrom. All other product names are trademarks or registered trademarks of their respective holders. Mention of non-Apple products is for information purposes and constitutes neither an endorsement nor a recommendation. Apple assumes no responsibility with regard to the selection, performance, or use of these products.
  264.  
  265. Updated November 13, 1997
  266.  
  267.